Intel® DMI 2.0 SDK Development Tools Version 1.0 Release Notes

THIS IS A PRODUCTION RELEASE. THE SOFTWARE CAN BE USED UNDER THE TERMS AND CONDITIONS OF THE LICENSE AGREEMENT.

This document contains information about the above product in the following sections:

1. Release Contents
2. Changes from the Previous Release
3. Target Environments
4. Technical Support Information
5. Installation Instructions
6. Operating Instructions
7. Product Release Notes

• MIF Conformance Checker (COMPCHK2.EXE) version 2.0.0.9.
• DMI 2.0 Component Test System (DCTS2.EXE) version 2.0.0.15.

1. Conformance Checking via Service Provider (SP):
   COMPCHK2 can connect via Remote Procedure Call (RPC) to a remote system. Currently, only Distributed Computing Environment (DCE) RPC is supported. This means that you can run COMPCHK2 on a Windows* 95 or Windows NT* system, and test conformance on other, non-Windows platforms (that support DCE RPC).
   
   
2. Additional standards of conformance, as defined by the DMI Specification Version 2.00, are checked.
   
   
3. Required Groups Checking:
   Allows users to define a minimum set of groups for compliance. An example of this is the Manageable Networked Computer Baseline. For conformance with this specification, all groups must be implemented on the Candidate system.

1. Remote Service Provider connections:
   DCTS2 can connect via RPC to any number of remote systems. Currently, ONC RPC and DCE RPC are supported. This means that you can run DCTS2 on a Windows 95 or NT system, and test DMI v2.0 SPs on other, non-Windows platforms (that support ONC RPC or DCE RPC).
   
   
2. DCTS2's test result output is simplified from the 1.x method. Test results are formatted into readable text and written to a window (the Test Monitor), or directly to a log file, or both. The Report Generator used by DCTS 1.x is no longer required.
   
   
3. Multiple browser windows can be opened at once. Each browser window can be assigned to a different system.

The internal database, used by DCTS2 during TEL construction, is now managed on a per-system basis. The data (a list of MIF files) used to build the internal database used to be part of the session data; it is now part of the system connection parameters.

One of the last steps in creating a TEL command is to choose whether or not to create an error condition test. This is controlled through a check box in the TEL dialog that is always cleared upon reaching this step. If this Error check box is checked, the Prev Step button is disabled, and backing up through the current command is no longer supported for the current command.

3) Target Environments
----------------------------------

Windows NT 3.51 and 4.0, Windows 95 and OSR2*.

These tools require the DMI 2.0 DCE Client from the DMI 2.0 Service Provider SDK Version 1.1 to be installed.

4) Technical Support Information
-----------------------------------------------

See the support information page.

5) Installation Instructions
---------------------------------------------

To install, download the self-extracting installation file, then follow the instructions on the screen.

For Windows NT, you must be logged into an account with privileges to create registry keys and files in order to install the SDK Development Tools.

SDK Installation - Known Problems / Issues

• If the installation program finds an existing copy of the DMI 2.0 SDK Development Tools executable, it does not allow the user to choose the target directory (it uses the old one, instead).
  
  Workaround
  Uninstall the previous version, or overwrite the current SDK Development Tools directory.

SDK Uninstall Known Problems / Issues

• No issues.

7) Product Release Notes
------------------------------------------

COMPCHK2 Known Problems / Issues

• The internal database does not handle OS identifiers for Windows 95 or Windows NT in MIF file Path statements. If a Path statement includes either of these identifiers, a syntax error is reported and the MIF is not installed. This applies only to the COMPCHK2 internal database; behavior of the DMI database is dependent on the Service Provider.
  
  Workaround
  The WIN32* Operating System (OS) identifier is handled correctly, so use it in your MIF files instead of Windows 95 or Windows NT. This should only be a drawback if your instrumentation is written specifically for one of these Operating Systems and does not work on the other.
  
  
• When closing the COMPCHK2 application or running a new conformance test, the user is not prompted to save unsaved data. The user must be cautious to save the results before performing new conformance tests or shutting down the application.
  
  
• During the Dependent Group checking of Pragma statements, COMPCHK2 only allows a null (wild card) to be used in the version portion of the class string. According to the DMI Specification Version 2.00, any portion of the class string can be null.
  
  
• During the Dependent Group checking of Pragma statements, if the Class String to be included is only in the candidate Pragma statement, COMPCHK2 does not verify the existence of the group containing this class string in the Candidate component.
  
  
• On some systems, COMPCHK2 cannot load MIF files when an attribute of type Date has a default value of "".
  
  Example:
  Start Attribute
  
  Name = "Installation"
  ID = 5
  Description = "The time and date of the last install of this component."
  Access = Read-Only
  Storage = Common
  Type = Date
  Value = ""
  
  End Attribute
  
  Workaround
  In the MIF file, enter any valid DMI date into the date value statement before attempting to load the MIF into the COMPCHK2 internal database.
  
  This behavior has been observed on some but not all systems, and is under investigation.

• The internal database does not handle OS identifiers for Windows 95 or Windows NT in MIF file Path statements. If a Path statement includes either of these identifiers, a syntax error is reported and the MIF is not installed. This applies only to the DCTS2 internal database; behavior of the DMI database is dependent on the Service Provider.
  
  Workaround
  The WIN32 OS identifier is correctly handled, so you can use that in your MIF files instead of Windows 95 or Windows NT. This should only be a drawback if your instrumentation is written specifically for one of these OSs and does not work on the other.
  
  
• The attribute value field in the browser window does not always show Octet string characters properly.
  
  
• Automatic browser updates on receipt of indications for Component Added or Component Deleted is not always correct.
  
  Workaround
  If you suspect that a browser window is not showing accurate information about a system, close the browser and re-open it for the system in question, or open a second browser window.
  
  
• There is no automatic browser update on receipt of indications for Languages or Groups Added or Deleted.
  
  Workaround
  As with Components Added/Deleted indications, if you suspect that the browser window is not up to date, close the browser and re-open it.
  
  
• When either of the Test Monitor or Event Monitor windows are closed, there is no warning given if the monitor's text has not been saved.
  
  Workaround
  The Test Monitor contents are duplicated in a log file, if you enable results logging (via the Preferences dialog) before executing your TEL.
  
  
• If the contents of the Test Monitor or Event Monitor window exceeds about 2000 lines (not hard to do, especially the Test Monitor!), the text wraps around vertically in the window and corrupts the display. This behavior occurs only under Windows 95, not under Windows NT.
  
  Workaround
  If the window contents are saved to disk via the Save Report or Save Report As commands in the File menu, the resulting text file contains the complete report, without error.
  
  
• When installing components from the DCTS2 Install menu, if the Both Databases option is selected, the component may not be flagged as available for test, even though both installations succeed. This is due to the latency time of AddComponent Indications being propagated through the system. This is more likely to occur on slower systems.
  
  Workaround1
  Install the component via a TEL. The indication latency is accounted for correctly for this installation path.
  
  Workaround2
  Install the component in two steps: First into the Service Provider database, then into the DCTS2 internal database. It is important that the installation into the SP database happen first.
  
  
• When the Max Simultaneous count is greater than 1 during a test run, commands may not be submitted to the Service Provider in the exact order they are defined in the TEL. This is due to thread timing issues and is beyond the control of DCTS2. Commands are logged in the same order they are defined in the TEL. Note that this logging order may indicate errors when none actually exist. For example, a DmiSetAttribute followed immediately by a DmiGetAttribute to the same attribute. The DmiGetAttribute may return the value of the attribute before the DmiSetAttribute, when in fact the DmiSetAttribute succeeded.
  
  Workaround
  None. This is an Operating System thread timing issue, beyond control of DCTS2.
  
  
• On some systems, DCTS2 can't load MIF files, when an attribute of type Date has a default value of "".
  
  Example:
  Start Attribute
  Name = "Installation"
  ID = 5
  Description = "The time and date of the last install of this component."
  Access = Read-Only
  Storage = Common
  Type = Date
  Value = ""
  
  End Attribute
  
  Workaround
  In the MIF file, enter any valid DMI date into the date value statement before attempting to load the MIF into the DCTS2 internal database. If the correct date value is important to your test, the internal value may be updated via the Scan A Component menu selection.
  
  This behavior has been observed on some but not all systems, and is under investigation.